前一篇得到某友人回饋表示看完後對於Sentry和ELK的選擇上有困惑，感謝友人讓我今天有題目可以寫XD

先對Sentry和ELK做點介紹，接著再指出我認為的差異處：

Sentry是基於事件(Event)的監控平台。

Event不見得是錯誤，也有可能是一個Debug, Info level的事件。這得看開發者怎麼去規劃，哪些功能出錯該噴Error等級的Event，哪些噴Fatal，哪些噴Warning等等...
通常我們會將回報給Sentry的方法和系統上的Log放在一起，尤其是在Log.error()，Log.fatal()這種特別嚴重的狀況時。因此Client端在操作過程中觸發Log時，便會發送給Sentry。

並且通常來說，用戶在操作過程中遇到預料外的狀況，例如閃退、資料出不來等等，都會反射性地去重新嘗試。

因此一樣的Event會重複發送到Sentry，這時我們會將它們歸類成一則Issue。

ELK

ELK是由Elasticsearch、Logstash和Kibana三個服務字母開頭所組成。

Logstash：

• Logstash 主要職責是抓取專案的Log同時會對Log做Formatted。
• 它主要做了三件事抓取、篩選、輸出。
• 抓取 來自各地各種類型的資料。
• 篩選 抓與來的資料，將每項數值給予對得上的欄位。
• 輸出 給你想讓他去的地方，這邊就是輸出給Elasticsearch，甚至可以直接寫進DB。

Elasticsearch：

• Elasticsearch 扮演著搜尋引擎的角色，它就是專注於把查詢功能做到最棒好。
• Logstash 把資料餵給Elasticsearch，因此能夠查詢的到Log。

Kibana：

• Kibana可以想像成是Elasticsearch的高級GUI介面。
• 提供給我們更加良好的操作體驗。
• 甚至支援圖表顯示這類功能。

也可以理解成Logstash 過濾，Elasticsearch 儲存，Kibana 展示

ELK額外發現：

Beat :

• Beat 是後來又出的輔助Logstash的一套服務，儘管他是在做Logstash也能做到的事，但他更輕量化，且不佔用系統資源。
• 因此Client可以改成接上一個Beat，將資料吐給Reids，接著Logstash到Redis抓取到那些Client端Log。
• 參考這張圖能更好理解ELK+Beat的生態體系
  
  源自：https://www.elastic.co/guide/en/beats/libbeat/current/beats-reference.html

Sentry vs ELK？

看到這漸漸明白這兩者是沒辦法比較的，
一個是著重於搜集異常的事件，
一個是著重於盡可能搜集所有Log，並且歸類整理它。

要我舉例來說兩者的差別的話：

以發生Produciton Issue來說

使用Sentry:

1. 某用戶反應：某功能無法正常使用。
2. Support：斷定為預期外的事件時，根據功能所屬開發團隊找到工程師協助。
3. 某工程師：檢查Sentry，查看後發現有新的NullException發生。
4. 某工程師：Sentry已提示Code Track，因此直接看那份Code哪邊出錯，發現沒有Handle到某情境。
5. 某工程師：嘗試修復，HotFix。

後面不贅述

使用ELK：

1. 某用戶反應：某功能無法正常使用。
2. Support：斷定為預期外的事件時，根據功能所屬開發團隊找到工程師協助。
3. 某工程師：打開ELK(開始爬Log)，有必要時會跟Support索取用戶資訊，加快找到關鍵Log。
4. 某工程師：找到Log了，知道是哪個檔案出問題，沒有Handle到某種情境，導致系統噴出NullException。
5. 某工程師：嘗試修復，HotFix。

後面不贅述

據我所知ELK和Sentry都有Send Alert功能，不過玩不夠透徹，不清楚ELK支援到多廣。

整體下來我的感受是時間花費的差距

Sentry 帶給我更專心於Exception的資訊，一則Issue需要的資訊都歸類放好了，我能很專心的去思考。且會出現在上面的Issue，通常都是有問題該解決的。
ELK 則是把所有你想知道跟你不想知道的東西都給你了，它保證了我能獲得足夠的資訊，我能更清楚來龍去脈，只是要花時間查。